Cross-Contract #40
Cross-Contract #40
Conversation
…dhat Signed-off-by: Ilja von Hoessle <ilja@perun.network>
Signed-off-by: Ilja von Hoessle <ilja@perun.network>
…ment Channels Signed-off-by: Ilja von Hoessle <ilja@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
feat(adjudicator, assetholder): optimize gas usage feat: remove safemath usage, over- and underflows are checked automatically since solidity 0.8.0 fix(test): remove pubkey from participant Signed-off-by: Sophia Koehler <sophia@perun.network>
.github/workflows/ci.yml
Outdated
|
|
||
| - name: Install dependencies | ||
| run: yarn | ||
|
|
||
| - name: Lint | ||
| run: npx solhint 'contracts/**/*.sol' | ||
|
|
||
| - name: Build | ||
| run: yarn build | ||
| - name: Install Hardhat and other dependencies |
There was a problem hiding this comment.
If you need these dependencies, why not add them to the dev dependencies? Unusual to install selected dependencies in workflow script.
How do you maintain security of such a cross-contract channel? Don’t you need virtual channels for that? Do you have a more detailed spec for that feature? |
We still rely on payment channels, but in go-perun, we allow multiple backends to be imported so that different implementations of the adjudicator and funder can be used within a single channel. To ensure security, we continue using the same encoding and signature methods across all backends. This ensures that a signature generated by one backend (e.g., the Stellar backend) can be verified on another backend and contract, such as Ethereum, and vice versa. |
|
@sophia1ch got it, i think that makes sense. thank you for outlining the approach! cheers! |
Signed-off-by: Sophia Koehler <sophia@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
| address app; | ||
| bool ledgerChannel; | ||
| bool virtualChannel; | ||
| } | ||
|
|
||
| struct Participant { | ||
| address ethAddress; | ||
| bytes ccAddress; |
There was a problem hiding this comment.
It is the L1 address for any other non-EVM chain, encoded in bytes. Currently, we support cross-chain Ethereum-to-non-EVM Payment Channels for the Stellar network (see our Stellar Contract and Backend Repositories).
But in principle we can implement channels between Ethereum and any chain that lets us emulate Solidity encoding within their respective contract (again, see our Stellar WASM contract). For Rust, there are proper crates to do this, so any L1 chain with Rust-based Smart Contracts is supported to have secure channels to Ethereum-based chains.
Yes, it is that awesome.
There was a problem hiding this comment.
ok, so you are allowing your participant identifiers to be multi-chain, right? wouldn't it have been cleaner to just use one abstract bytes field then? what if you have more than two chains?
more concretely, what looks odd to me here is that this is not symmetric anymore. like you are treating the eth network as a special case, while all other networks would go under ccAddress.
* feat(.sol): Change channelID array to singular channelID and remove unnecessary functions Signed-off-by: Sophia Koehler <sophia@perun.network> * fix(Assetholder): Remove immutable flag fix(ci.yaml): Add immutable-state to slither exclusion Signed-off-by: Sophia Koehler <sophia@perun.network> --------- Signed-off-by: Sophia Koehler <sophia@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
Signed-off-by: Sophia Koehler <sophia@perun.network>
This PR introduces cross-contract payment channels. This is implemented by adding a backends field to the allocation, changing the channelID to an array of channelIDs and changing the participant struct to include addresses from other blockchains.